Brief Full Advanced Search Search Tips
|  |  | To access the contents, click the chapter and section titles. Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 Search this book:
Previous | Table of Contents | Next
## Chapter 24 Client/Server Programming Client/server computing is a powerful tool that is applicable to many data-processing needs. Finding a personal computer that exists in isolation, without being part of a network, is becoming more and more difficult. Networked computers are the norm, particularly in the workplace. Why are networks becoming so prevalent? The main reason is the need to share information. Whether it is a product catalog, technical-specification summary, or accounting data, most of the information that businesses and organizations deal with is used by more than one person. Networks have the potential to provide other benefits, as well. Modern networks use an approach called client/server architecture, and Visual Basic provides the tools that developers need to use this technology. This chapter covers the basics of client/server computing, as implemented in Visual Basic. Client/server programming is an enormously complex topic, so please do not expect more than a brief introduction in this chapter. My goal is merely to acquaint you with the capabilities of this approach and introduce you to some of the tools that Visual Basic provides to implement client/server applications. Be aware that most of the tools required to implement client/server applications are available only with the Enterprise Edition of Visual Basic. ### Some Background Back in the old days, 20 and 30 years ago, computers were large, expensive devices that required a lot of care and attention. Each person who needed computer power couldn’t possibly have his or her own computer. The solution was to keep the computer, or mainframe, at a centralized location and provide each user with a terminal (screen and keyboard) that was connected to the mainframe. The terminals were referred to as dumb terminals, because they possessed no data-processing power of their own—they served merely to accept keystrokes and send them to the mainframe, and to receive data from the mainframe and display it. Both the data and the application logic (programs) were located on the mainframe. This approach, sometimes called a centralized architecture, worked well enough in many cases, but it had the disadvantage of all the application logic being located on the central mainframe, which meant that one computer had to perform all data-processing tasks. No matter how powerful the machine, it could still get bogged down with multiple requests, resulting in a slow response time from the user’s perspective. The introduction of personal computers (PCs) didn’t remove the need to share information. The first solution to sharing data was jokingly called “sneaker-net,” because you would copy the needed information to a diskette then run down the hall to give it to whoever needed it. A more realistic way to share data was the file server architecture, in which each user had his or her own computer, or workstation, connected to a shared file server via the network. The file server itself was a “personal” computer, typically with beefed up memory and a large hard disk. The data that needed to be shared was located on the file server, while the application logic, or programs, were located on the individual workstations. When a user needed some shared information, a request was sent to the file server, which opened the relevant file and transferred the file over the network to the user’s workstation, where all data processing was performed. The file server also permitted users to share physical resources, such as printers and modems. The file server architecture worked perfectly well, but it had some negative points that were almost the reverse of the problems with the centralized architecture discussed earlier. Because all processing was performed on the workstations, each individual workstation had to be powerful enough—processor speed, memory, and so forth—to perform all the computing tasks required by the user. While an individual PC may not cost too much, providing dozens of users with state-of-the-art machines can make a significant dent in anyone’s budget. TIP: Multiuser Database Considerations Visual Basic is commonly used to create database implementations that are designed to run in a file server environment. When a database is designed for simultaneous use by multiple users, the transaction-processing front ends must be concerned with the concurrency and the consistency of the database tables. Concurrency problems can arise if two or more users attempt to update the same record simultaneously. The outcome of the simultaneous update requests may not be predictable—one update or the other may prevail. Consistency problems may occur when one user updates a set of records, and another user attempts to view those records while that transaction is in progress. The data the second user sees may be incorrect, reflecting only part of the update transaction. The solution to both concurrency and consistency problems involves locking the record during an update, thus preventing any other user from accessing the record until the update is completed. Concurrency problems are prevented, because one update is forced to wait until the other update is completed, ensuring that both updates are reflected in the record. Consistency problems are avoided, because the second user can’t access and view the records until the first user’s update transaction is completed. Advances in programming and hardware technology led to the development of the client/server architecture. In this architecture, the strong points of the centralized and file server architectures are combined, while avoiding the weak points of both. Two separate application programs, one running on the server computer and the other on the client computer, cooperate to perform the required task. Data-processing chores are split between two machines, enabling more efficient allocation of computing resources. Data transfer across the network is minimized, also. A couple examples of the client/server architecture are presented next. Shared hardware resources, such as printers, are an important part of the client/server architecture. When a client needs to print a document, the application on the client computer (a word processor, for example) sends the document across the network to the server computer. On the server computer, a separate program, called the Print Manager, accepts the document, places it in the print queue, monitors the progress of printing, and notifies the client computer when the printing job is complete. The preceding example is accurate, but somewhat trivial. A much more important use of the client/server architecture is in a database management system (DBMS). The next example illustrates the contrast between the operation of a file server architecture and a client/server architecture.
Previous | Table of Contents | Next

| Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.